In network configurations, error conditions can cause serious problems. One particularly troublesome error condition is known as a call loop. The call loop is characterized by a call that is never connected nor released, thereby using resources indefinitely. The call loop can be caused by unintentional configuration problems or intentionally by a malicious person creating mischief or attempting to harm a network. A network that experiences one or more call loops can have performance issues because the loops can tie up resources. Without enough available resources, the network may slow down or become unusable.
Session Initiation Protocol (SIP) is a signaling communications protocol used in some networks that has a few built in mechanisms to break the call loop when it occurs. In a network that contains all SIP-enabled elements, SIP can detect and break a loop when a call dialog that is creating requests gets stuck in a loop. The mechanism has a User Agent Client (UAC) insert a Max-Forwards header (default value 70) in an initial call request. Each SIP proxy in the request path typically decrements the Max-Forwards header value by one. When the Max-Forwards value reaches zero, the request is rejected and the call loop is broken. As an optional anti-looping measure, the SIP proxies may also check whether the same request is a repeat by inspecting the contents of the Via header. However, when there are back-to-back user agents (B2BUA), a Protocol Interworking Gateway (IWG), and/or other non-SIP elements in a loop path, the Max-Forwards and Via headers cannot be relied on to detect the loop since not all elements in a network are pure SIP proxies. Non-SIP elements may not be capable of decrementing headers and/or inspecting the contents of headers for repeats. Call loops may not be discovered and broken or may not be detected at all when non-SIP elements are present.